ROM estimates and what we often forget

2026-10-19T08:30:00.000Z

“Why are you spending time on that? It wasn’t in the original estimate!”

I’ve heard variations of this many times. Different projects, dfferent people.

In my previous two posts I’ve discussed why ROM estimates are necessary and how creating one can help surface risk early.

There’s one final aspect to ROM estimation that I’ve not yet covered: the work we tend to forget to estimate. In my experience surprises don’t usually come from the estimated work (the coding, test, integration and so on). Some estimates are over, some under but over the course of a project they often broadly balance out.

The surprises come from the work that we didn’t explicitly recognise at the start, some of which can be particularly time consuming. We know that we’ll probably encounter some (or all) of them yet we don’t often explicitly account for them in the ROMs, things like:

• Time spent building prototypes to explore an unfamiliar problems, tools or software.
• Waiting for decisions that require several stakeholders.
• Integrating with hardware or third-party components that behave differently from the documentation.
• Integrating with hardware that doesn’t initially work

None of this work is unusual. In fact, much of it is predictable. The difficulty is that these activities often remain implicit when estimates are produced.

Then there’s another category of work that is frequently underestimated: We estimate:

• Requirements capture
• Implementation
• Testing
• Documentation
• Integration

But we rarely estimate enough time for:

• Stabilisation
• Bug fixing
• Integration churn
• and “ironing out the creases”

In many software systems, that final phase often determines whether the product actually feels robust. Importantly, it’s hardly ever a single iteration - but that’s often all we estimate for.

And then there’s the release process. The product isn’t finished just because the software has been built and tested. Someone still has to:

• Build the release artefacts
• Version and baseline everything correctly
• Prepare documentation
• Distribute software
• Communicate what changed
• Support deployment into the wider business or customer environment

That work is essential, but it’s often absorbed informally rather than estimated explicitly. None of these things are problems. They are normal parts of building and delivering real systems. But the effort isn’t free, and if we don’t recognise it in the ROM estimate, it still has to come from somewhere.

Over time I’ve found it helps to call these things out early. Making them visible allows the business to make better decisions about risk, schedule and investment.

And that is usually the real value of an early estimate.

Post 3/4 on estimating software projects.